-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check if the read lock is held before exiting #1639
base: master
Are you sure you want to change the base?
Conversation
Check if the read lock is held before exiting.
@@ -10,7 +10,7 @@ namespace LiteDB.Tests.Engine | |||
{ | |||
public class ParallelQuery_Tests | |||
{ | |||
[Fact(Skip = "Must fix parallel query fetch")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Voila! the parallel query works with this change.
@@ -54,7 +54,8 @@ public void ExitTransaction() | |||
// if current thread are in reserved mode, do not exit transaction (will be exit from ExitExclusive) | |||
if (_transaction.IsWriteLockHeld) return; | |||
|
|||
_transaction.ExitReadLock(); | |||
if (_transaction.IsReadLockHeld) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check before exiting, otherwise ExitReadLock throws System.Threading.SynchronizationLockException:The read lock is being released without being held
@huyhu Does this actually fix your use case? Do you have any tests for this PR? I'm worried this PR only masks an underlying issue (why did the transaction try to release a lock that it didn't hold in the first place?) |
I would agree it is important to find the underlying cause of the issue, however, adding this check does stop a fatal exception that takes down an application. I, too, have encountered this error several times in the past few months, and I have not been able to isolate it to anything in particular. (I am using the mutex locking scheme--ie. direct--with async tasks, request the least permission necessary for db activity, and wait retries where applicable). Perhaps adding -- if (held) {remove} / else {log} -- type of solution would suffice without reviewing all the locking logic and retaining this bug. |
Check if the read lock is held before exiting.